关于可执行的控件
在此部分：
受信任的所有权
在规则匹配过程中，对文件和文件夹执行“受信任的所有权”检查，确保项目的所有权与默认规则配置中指定的可信所有者列表匹配。
例如，如果要运行的文件与允许的项目匹配，则执行额外的安全检查可确保文件所有权也与“可信所有者”列表匹配。 如果原始文件被篡改，或存在安全威胁的文件被重命名来仿冒允许的文件，则受信任的所有权检查会识别到其不规则性并阻止文件执行。
默认情况下拒绝网络文件夹/共享。 因此，如果文件保存在网络文件夹中，则必须将该文件或文件夹作为允许的项目添加到规则中。 否则，即使该文件通过了受信任的所有权检查，规则也不会允许访问。
因为签名无法模仿，所以不必对有文件签名的项目执行受信任的所有权检查。
默认信任的所有者为：
- 系统
- 内建\管理员
- %ComputerName%\Administrator
- NT 服务\可信安装者
这意味着默认情况下，应用程序控件 信任“内建\管理员”组和本地管理员拥有的文件。 应用程序控件 对“可信所有者”不执行组查找 - 默认情况下，不信任“内建\管理员”组的用户。 其他用户（包括“管理员”组的成员）必须经过明确添加才能成为“可信所有者”。 可通过扩展“可信所有者”列表添加其他用户或组。
技术
应用程序控件 使用安全过滤驱动程序和 Microsoft NTFS 安全策略来拦截所有执行请求。 执行请求完成 应用程序控件 挂钩，阻止任何不想要的应用程序。 应用程序权限基于应用程序的所有权，默认的受信任的所有权通常属于管理员。 通过使用此方法，无需脚本或列表管理就可强制执行当前的应用程序访问策略。 这称为受信任的所有权。 除了可执行文件之外，应用程序控件 还管理应用程序内容（如 VBScripts、批处理文件、MSI 程序包和注册表配置文件）的权限。
受信任的所有权是 应用程序控件 中应用程序访问的默认控制方法。 它使用自由访问控制 (DAC) 模型。 它对文件的所有者属性进行检查，并将其与预定义的可信所有者列表进行比较。 如果文件的所有者出现在列表中，则允许其执行文件，否则拒绝执行。
此安全方法的一个重要功能是能够不考虑文件内容本身。 通过这种方式，应用程序控件 能够同时控制已知和未知的应用程序。 常规的安全系统，如反病毒应用程序，将文件模式与已知列表中的模式进行比较，以识别潜在的威胁。 因此，它提供的保护与它用于比较的列表的准确性成正比。 许多恶意软件应用程序要么永远无法识别，要么最多只能在一段时间后当系统比较脆弱时才能识别。 默认情况下，如果可执行文件的所有者列在配置中的可信所有者列表中，那么 应用程序控件 将允许所有本地安装的可执行内容执行。 然后，管理员必须提供他们不希望从本地磁盘子系统执行的应用程序列表，它们通常是管理应用程序，比如 mmc.exe、eventvwr.exe、setup.exe 等。
如果采用这种方法，则管理员无需了解应用程序设置为函数所需的每一段执行代码的详细信息，因为受信任的所有权模式可根据实际情况允许/拒绝访问。
当 应用程序控件 被引入系统时能够阻止任何基于可执行脚本的恶意软件，应用程序控件 不用于取代现有的恶意软件删除工具，但应作为辅助技术。 例如，虽然 应用程序控件 能够阻止病毒的执行，但无法将其从磁盘清除。
受信任的所有权规则
受信任的所有权无需考虑登录用户。 登录用户是否为可信所有者或管理员并不重要。 哪个用户（或组）拥有磁盘上的文件是受信任的所有权的中心内容。 通常为创建文件的用户。
通常将 应用程序控件 控制台中的“内建\管理员”组视为文件所有者。 文件所有者可能是单个管理员的帐户。 这导致下列情况：
- 文件所有者是“内建\管理员”组，且此组是可信所有者。 “受信任的所有权”允许执行文件。
- 文件所有者是单个管理员，且该单个管理员是可信所有者。 “受信任的所有权”允许执行文件。
- 文件所有者是单个管理员，且单个管理员不是可信所有者，但是“内建\管理员”组是可信所有者。 受信任的所有权不允许执行文件。
在最后一种情况下，尽管拥有文件的管理员位于“内建\管理员”组中，但文件所有者不受信任。 未扩展该组以了解单个所有者是否值得信任。 在这种情况下，为了允许文件执行，必须将文件的所有权更改为属于可信所有者（例如域或本地管理员）。
安全级别
应用程序控件 规则允许您设置安全级别，指定如何管理由规则匹配的用户、组或设备运行未经授权的应用程序的请求。
自授权
在某些环境中，有些用户必须向计算机添加新的可执行文件，例如不断更新或测试内部软件的开发人员，或需要访问新应用或未知应用程序的高级用户。 自授权允许指定的高级用户执行其引入系统的应用程序。 这些高级用户可以在办公室外向安全端点添加应用程序，而无需依赖 IT 人员的支持。 这为开发团队、高级用户和管理员提供了安装和测试软件的灵活性，同时仍然能够提供高级别保护，以免受到隐藏恶意软件和可执行文件的影响。
所有配置为自授权的用户都可以选择每次在当前会话期间运行一次或始终运行不可信执行文件。 全面审计包括应用程序名称、执行日期和时间以及设备等详细信息。 另外，还可以集中获取并存储应用程序副本以供检查。
允许的和拒绝的项目
允许的项目
允许列表方法规定，用户对操作系统上的应用程序发出请求之前，必须先预定义每个可执行内容。 以这种方式标识的所有内容的详细信息都保存在一个允许列表中，每次执行请求时都必须检查该允许列表。 如果可执行文件在该允许列表中，则允许执行；否则将拒绝执行。
一小部分安全技术以这种方式工作，但是它们在执行后通常会遇到与所需管理级别有关的问题。 这是由于需要向允许列表添加所有修补程序、产品等级和升级并进行维护。
应用程序控件 完全支持这种控制模型，并添加了重要的步骤来启用模型中的附加安全性。 其中一个附加功能是包含 SHA-1、SHA-256 和 Adler-32 数字签名，这样不仅应用程序名称和文件路径必须匹配，而且可执行文件的数字签名也必须与数据库中的签名匹配。 此外，应用程序控件 还将可执行文件的完整路径添加到列表，以确保所有三个项目在应用程序执行之前均匹配：
文件名 - 比如 winword.exe。
文件路径 - 比如 C:\Program Files\Microsoft Office\Office\digital signature
要将该技术引入控制的下一个阶段，应用程序控件 不仅包含可执行程序的详细信息，还要求管理员指定特定的 DLL 以及所有其他可执行内容，比如 ActiveX 控件、Visual Basic 脚本和命令脚本。
在 应用程序控件 中，允许列表称为“允许的项目”。 “允许的项目”列表中的项目包括：
- 文件
- 文件夹
- 驱动器
- 文件哈希
- 规则集合
拒绝的项目
与允许列表相比，拒绝列表是一个潜在的低安全性措施。 生成列表（包含要拒绝执行的应用程序）并对其进行维护。 这是该方法的主要缺点，因为它假定所有危险的应用程序实际上都是已知的。 这对大多数企业来说用处不大，特别是具备电子邮件和 Internet 访问权限和/或用户可以在无需管理员干预的情况下引入文件和应用程序的企业。
应用程序控件 不需要积极维护被拒绝的应用程序列表，因为任何未安装的应用程序（因此由管理员拥有）都是通过使用受信任的所有权拒绝的。
通过拒绝列表禁止应用程序的主要原因之一是为了将“受信任的所有权”用于许可证管理，因为此方法可以禁止运行已知的（即信任且拥有的）应用程序，直到管理员定义特定的用户/组或客户端规则，以明确允许访问该应用程序。 除了允许外部应用程序之外，此保护不需要配置。 此外，对于受信任所有者拥有的文件，如因存在安全风险需要拒绝访问，则拒绝列表非常有用。 比如，regedit.exe、ftp.exe 等。